Conventional development of call flow models involves writing a single script to represent the full life cycle of the call flow. All logic required for the handling of conditions, problems and solutions represented in the call flow are encompassed by a single script. Blocks of logic are recreated repeatedly to provide logic that is common to different parts of a call flow or to multiple call flows. For example, multiple call flows include logic to validate a customer's identity based on the customer's social security number (SSN). If this validation logic becomes more stringent by adding a request for an employee ID in addition to the SSN, each occurrence of the validation logic in each affected call flow needs to be updated with the added validation step.
To overcome the aforementioned problem, certain known systems provide scripts that “include” or “import” other scripts. This technique allows common logic to be separated and specified in a script which is then referenced as needed from all other scripts employing that logic. This ability eliminates the nuisance of having to reconstruct or update the common logic in multiple places.
However, call flow tasks are often composed of multiple sub-tasks whose behavior varies depending upon various conditions present when the call flow is executed. Difficulties arise due to the interdependent nature of the call flow logic, as changes to the sub-task logic require changes in the parent task logic as well. Such changes to parent task logic are required, for instance, when (1) the number of relevant conditions to a sub-task increases, or the response to these conditions changes, or (2) additional ways of rendering or performing a particular sub-task develop over time.
For example, the type of customer validation described above depends on various factors, including the type of customer. For an internal customer, the validation is done based on the employee ID and the manager's ID. For an external customer, the customer service representative asks for a support contract number. Based on contractual agreements, different questions need to be asked for validation purposes. As these contracts change, the current system requires changes to the actual contractual logic script, as well as updates to the conditional logic within every parent call flow script that invokes the appropriate validation script. Additionally, if additional types of validations need to be carried out (e.g., validating contracting employees), there is no seamless way to introduce the additional types without modifying the parent call flows. Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.